Hi @mrkane27, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

Sorry - Commented on the issue instead of the PR.

Thanks for this cool fix. We would love to take it after adding a failing test in the current code, that gets fixed by this change.

Thanks for replying!

As far as I can tell, the issue only happens on Linux and Mac, using Mono.
Do you run tests on any of those? If yes, could you point me to where I should add a test? -- I've never contributed to this repository before.

Ah - Cool.

We are not yet running tests on mac and linux regularly (but in fact that is what half the team is doing this week, making it all happen for core clr).

Lets do this for now

1. Add a comment that this only happens on mono
2. We will try that with the new nuget.commandline.xplat package (to make sure it doesn't repeat there)
3. Add a follow up test, once we have the linux tests passing properly (we are still tracking a few tens of test failures)

A different take might be to use System.Console.IsOutputRedirected and default to e.g. a width of 80, which would make sense for file output -- but that might be overkill for this fix.

I like this new idea better. Lets update to it or does not sound like an overkill.

We are running tests on Linux on a CI regularly starting from this week.

I thought about this for a bit more, and it might not actually work. For example, if you do nuget ... | cat, you might still want it formatted for the terminal. I don't think there's a reliable way to determine whether the final output is into a file. What do you think?

I've also run some tests on how Console behaves on .NET and Mono, if you want to take a look.

I think the key is to unblock the hang. In general we are moving NuGet off mono and moving it gradually to coreCLR on unix (see nuget.commandline.xplat package), so coming up with something reasonable (like your suggestion of 80 chars) might be good enough. And then on coreCLR we can try to get things fixed.

Is this current state what you had in mind?

@mrkane27, Thanks for the tests on how Console behaves on .NET and Mono. I have checked it out. Your fix looks good to me too. I have merged it with 6afc0ac